Debugging, validating, and/or exercising bus connections between and/or within integrated circuits has conventionally been difficult. While tools exist to determine whether there is a short circuit or an open circuit associated with bus paths, these tools have typically been static tools that are unsuitable for at-speed bus validation. While a short circuit is a short circuit at any speed, other electrical problems may only appear at strenuous speeds.
Some conventional tools associated with bus validation may employ conventional techniques like ECC (error checking and correcting) or parity checking to detect bus errors. Upon detecting an error, these tools may generate an HPMC (high priority machine check). While post-mortem crash dump data may be available, this data may be of limited value. For example, the data may not be associated with the cycle in which it was detected, may not identify events that lead up to the crash condition, may not facilitate triggering a temporally meaningful test event, and so on. Additionally, these tools are conventionally designed for run-time error detection, containment, and so on.
Conventional bus validation tools and techniques may rely on existing protocols associated with a bus. However, using such protocols makes it difficult, if possible at all, to generate interesting test patterns and to send them at known and/or predictable times in known and/or predictable sequences to facilitate coordination with other actions like monitoring an oscilloscope. Thus, these conventional tools may be held hostage to normal codes a chip/bus combination could produce. Additionally, these conventional tools may rely solely on techniques like varying parameters like voltage, temperature, and frequency to validate a bus. Once again, while this may provide some data, rigorous at-speed electrical validation is not achieved.
Many conventional bus validation tools require integrated circuits that are to be connected by the bus to be substantially complete before bus validation occurs. This produces a chicken and egg problem related to serial development. Thus, integrated circuit development, firmware development, and bus validation may be tightly coupled producing lockstep serial development scenarios.
Conventional tools may also require the physical attachment of electrical probes like those associated with an oscilloscope or protocol analyzer. With increasing chip densities and circuit densities, and correspondingly decreasing trace, path, and wire sizes, such physical attachments are becoming ever more difficult.
Additionally, conventional tools may not produce conditions rigorous enough to evaluate problems associated with inter-symbol interference (ISI) and the like. By way of illustration, the history of data driven on a bus line may influence timing of a future data symbol on that line. However, the effects may only appear at certain higher frequencies since these effects may depend, for example, on line geometry, line length, line resistance, line capacitance, and so on. By way of further illustration, conventional tools may not be able to create conditions like saturated bus traffic situations. Additionally, due to complex bus protocols, even if a condition can be created once, it may be difficult to reliably recreate the condition on demand to facilitate validation and diagnosis.
Some tools even facilitate providing small patterns to facilitate boundary scanning. For example, the IEEE 1149.1 standard describes a boundary scanning protocol provided by the Joint Test Action Group (JTAG). However, such boundary scanning is essentially a static (dc) test. Additionally, the serial architecture associated with this type of boundary scanning does not facilitate at-speed electrical validation.